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Abstract 

This paper is a tutorial on algebraic effects and handlers. In it, we explain what algebraic effects are, give 
ample examples to explain how handlers work, define an operational semantics and a type & effect system, 
show how one can reason about effects, and give pointers for further reading. 
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Algebraic effects are an approach to computational effects based on a premise that 
impure behaviour arises from a set of operations such as get & set for mutable store, 
read & print for interactive input & output, or raise for exceptions [16,18]. This nat- 
urally gives rise to handlers not only of exceptions, but of any other effect, yielding 
a novel concept that, amongst others, can capture stream redirection, backtracking, 
co-operative multi-threading, and delimited continuations [21,22,5]. 

I keep hearing from people that they are interested in algebraic effects and 
handlers, but do not know where to start. This is what this tutorial hopes to fix. 
We will look at how to program with algebraic effects and handlers, how to model 
them, and how to reason about them. The tutorial requires no special background 
knowledge except for a basic familiarity with the theory of programming languages 
(a good introduction can be found in [8,15]). 
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value v : 

,:= x 


variable 


| true | false 


boolean constants 


fun x y-t c 


function 


1 h 


handler 

handler h : 

::= handler {return x \ — >• c r , 


(optional) return clause 


op 1 (a;; k) t-t ci, . . 

. . op„(x; k) i-> c„} 

operation clauses 

computation c : 

::= return u 


return 


| op (y;y.c) 


operation call 


| do x ci in C 2 


sequencing 


if v then c\ else C 2 


conditional 


| V\ V2 


application 


| with v handle c 


handling 


Fig. 1. Syntax of terms. 


1 Language 

Before we dive into examples of handlers, we need to fix a language in which to 
work. As the order of evaluation is important when dealing with effects, we split 
language terms (Figure 1) into inert values and potentially effectful computations, 
following an approach called fine-grain call-by-value [13]. There are a few things 
worth mentioning: 

Sequencing In do x <— C\ in C 2 , we first evaluate C\, and once this returns a value, 
we bind it to x and proceed by c^- If x does not appear in C 2 , we abbreviate the 
sequencing to c -\ ; . 

Operation calls The call op(u; y. c ) passes a parameter value v (e.g. the memory 
location to be read) to the operation op, and after op performs the effect, its result 
value (e.g. the contents of the memory location) is bound to y and the evaluation 
of c, called a continuation, resumes. However, note that encompassing handlers 
may override this behaviour. 

Generic effects Having an explicit continuation in the call is convenient for the 
semantics, but less so for a programmer, who just wants to get back the result 
of an operation. So, instead of a full-blown operation call, we define a function, 
called a generic effect [18], also labelled as op, which takes a parameter and passes 
it to an operation call with the trivial continuation: 

op = f fun x i — ^ op(x; y. return y) 

Though simpler to use, generic effects are just as expressive because we can recover 
the operation call op(u; y. c ) by evaluating do y <s— opn in c. 

Language extensions To focus on new constructs, we shall keep our language 
small, but for examples, we are going to extend its values with integers, primitive 


1 The material is based upon work supported by the Air Force Office of Scientific Research, Air Force 
Materiel Command, USAF under Award No. FA9550-14-1-0096. 
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arithmetic functions, strings, recursive functions rec fun / x i— > c, the unit () 
and pairs (v\,V 2 )- Furthermore, we allow patterns in binding constructs (func- 
tions, handler clauses, operation calls, and sequencing). In particular, we use 
the pattern _ to denote ignored parameters, and a pair pattern ( X\,X 2 ) to ex- 
tract components from a pair. For example, we bind 7 to a; and ignore 8 in the 
application (fun (#,_) H- 6 + x) (7, 8). 

Separation of values & computations We were a bit lax about the separation 
of values and computations when writing the last example. Since the addition 
6 + a; is in fact a double application ((+) 6) x , the first application (+) 6 is already 
a computation. Thus, it cannot be applied to x because both subterms of an 
application must be values. Instead, we need to use sequencing and write the 
example in our restricted syntax as: 


(fun ( x , _) H do f <— (+) 6 in f x) (7, 8) 


However, this longer form adds little value and makes examples hard to read, so 
while keeping it in mind, we are going to use the shorter form from now on. 

Conversely, we shall implicitly insert return whenever we use a value where 
a computation is expected. For example, we shall write fun x K > fun y >■ ( x , y ) 
instead of fun x return (fun y i— > return ( x , y)). 

Semantics Observe that each operation call creates a branching point in the eval- 
uation, with as many branches as there are possible results that can be yielded to 
the continuation. For example, decide will have two branches, print just one, and 
read will have infinite many branches: one for each possible input. Thus, we can 
imagine computations as trees, whose leaves are returned values and branching 
points are called operations. For an example, see Figure 2. 


print “A”; 
do n <— get () in 
if n < 0 then 
print “B”; 
return — n 2 
else 

return n + 1 


print “A” 



Fig. 2. A computation and a corresponding tree. 


In the presence of recursion, some of the leaves of the tree may also be labelled 
by J_ to indicate a divergent computation that does not call any operations. A 
divergent computation that repeatedly calls operations is represented by a non- 
well-founded tree. Denotational semantics is further discussed in Section 6.3. 
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2 Examples 

We now informally describe the behaviour of handlers through examples. You may 
also prefer to first take a look at the operational semantics given in Section 3. 

2.1 Input & output 

Let us start with input & output as it is a very simple algebraic effect, but one 
which exposes almost all important aspects of handlers. It can be described by two 
operations: print, which takes a message to be printed and yields the unit value (), 
and read, which takes a unit value and yields a string that was read. For example, 
a computation that asks the user for his forename and surname and prints out his 
full name, is written as: 

dcf 

printFullName = print “What is your forename?”; 

do forename read () in 
print “What is your surname?”; 
do surname <— read () in 
print (join forename surname) 

where join is a function that takes two strings and joins them with a space in the 
middle. 

2.1.1 Constant input 

A simple example of a handler is: 

handler (read(_; k) H » k “Bob”} 

which provides a constant input string “Bob” each time read is called. We can, of 
course, generalise it to a function that takes a string s and returns a handler that 
feeds it to read: 


alwaysRead = fun s H > handler (read(_; k) H > k s} 

This handler works as follows: whenever read is called, we ignore its unit parameter 
and capture its continuation in a function k that expects the resulting string and 
resumes the evaluation when applied. Next, instead of calling read, we evaluate 
the computation in the handling clause: we resume the continuation k, but instead 
of reading the string from interactive input, we yield the constant string s. The 
handler implicitly continues to handle the continuation, so any read in the handled 
computation again yields s. If the handled computation calls any operation other 
than read, the call escapes the handler, but the handler again wraps itself around the 
continuation so that it may handle any further read calls. For example, evaluating 


with (alwaysRead “Bob”) handle printFullName 
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first prints out “What is your name?” as print is unhandled. Then, read is handled 
so “Bob” gets bound to forename. Similarly, the second print is unhandled, and 
in the second read, “Bob” gets bound to surname as well and finally “Bob Bob” is 
printed out. 

It is not obvious whether handlers should continue handling operations in the 
continuation, or handle just the first call. Experience with exception handlers offer 
us no guidance here, because raised exceptions have no continuation, and so the two 
choices are equivalent. As it turns out, the first choice, which we are settling on in 
this paper, has nicer denotational semantics, is what one usually desires in practice, 
and is perhaps also more intuitive because with h handle c suggests that the 
whole c should be handled by h. The second choice leads to shallow handlers [10], 
which are more convenient for certain uses, and can be considered a more elementary 
approach as they can express the usual handlers through recursion. 

2.1.2 Reversed output 

We can use handlers to not only change what is fed to the continuation, but also 
to change the way the continuation is used. For example, to reverse the order of 
printouts, we use: 


reverse = handler {print(s; k) i— >■ k (); print s} 

Here, we handle a print by first calling the continuation, and only after this is 
finished, print out s. Since the handler wraps itself around k, the same rule applies 
for the continuation and so all printouts are reversed. So, if we define 

abc = f print “A”; print “B”; print “C” 

then with reverse handle abc prints out first “C”, then “B”, and finally “A”. 

2.1.3 Collecting output 

A more useful handler is one that collects all printouts into one big string and 
returns it together with the final value: 

collect = f handler {return x i— >■ return (x, “”) 
print(s; k) i->- 
do (x, ace ) <— k () in 
return (x, join s acc)} 

If the handled computation does not print anything and just returns some value x, 
we need to handle it by returning an empty string in addition to x. But if a 
computation prints some string s, we resume the continuation. Since this is handled 
in the same way, it returns the accumulated string acc in addition to the final value x. 
Now, we only need to join s with acc and return it together with x. If we handle 
abc with collect, we get a pair ((), “A B C”), where () is the unit result of the last 
print. 
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We can also nest handlers, and 

with collect handle (with reverse handle abc) 

evaluates to ((), “C B A”). The order in which we nest the handlers is significant as 
it is the innermost handler that determines how to first handle the call. If we switch 
the handlers in the above example, we get ((), “A B C”) because collect handles all 
print calls, and so none reach the reverse handler, which then does nothing. 

Alternatively, we could implement the same handler using a technique called 
parameter-passing [22] , where we transform the handled computation into a function 
that passes around a parameter, in our case the accumulated string: 

collect = f handler {return x H > fun acc return (x, acc ) 
print(s; k) 

fun acc i y ( k ()) (join accs)} 

When a computation returns a value x, there will be no further printouts, so we can 
return the given accumulator acc in addition to x. But if print is called, we resume 
the continuation by yielding it the expected unit result. Since the continuation is 
further handled into a function, we need to pass k () the new accumulator, which is 
acc extended with s. To obtain the collected output of a computation c, we apply 
the resulting function to the empty accumulator as: 

(with collect handle c) 

In Section 5, we show that collect and collect' indeed exhibit equivalent behaviour. 
Using parameter-passing, we can also implement a converse handler that feeds words 
from a given string to the input. 

2.2 Exceptions 

Exception handlers are, of course, a special instance of handlers. We represent 
exceptions with an operation raise that takes an exception argument (e.g. error 
message) and yields nothing to the continuation (for more details on how this can 
be enforced, see Example 4.1). 

In practice, exception handlers are rarely reused, but an example of a more 
general exception handler is: 

default = f fun x > handler (raise (-; -) ^ return x} 

which returns a default value x in case the handled computation raises an exception. 

2.3 Non- determinism 

Handlers can be used not only to override existing effectful behaviour, but to define 
new one as well. To implement non-determinism, we take a single operation decide, 
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which takes a unit parameter, and non-deterministically yields a boolean. Then, a 
binary choice can be implemented as a function 

choose = f fun (x. y) H- 

do b decide () in 

if b then (return x) else (return y) 

However, unlike print, we assume no intrinsic behaviour for decide, and we must use 
handlers to determine whether to return a fixed result, a random result, an optimal 
result, or all results. Without an encompassing handler, an application choose (3, 4) 
is stuck when it encounters the decide call. The simplest handler for decide is 

pickTrue = f handler {decide(_; k) i-)- k true} 

which makes each decide yield true to the continuation, so choose always chooses 
the left argument. So, if we define 

chooseDiff = f do x\ <— choose (15, 30) in 
do X 2 <— choose (5, 10) in 
return {x\ — X 2 ) 

then with pickTrue handle chooseDiff will choose 15 for x\ and 5 for X2, and will 
thus evaluate to return 10. 

2.3.1 Maximal result 

With handlers, we can also traverse all possible branches to select the maximal 
result: 

pickMax =* handler {decide(_; k) H- 

do Xt <— k true in 
do Xf <— k false in 
return max (xt,Xf)} 

In this case, evaluating with pickTrue handle chooseDiff will make the choices 
needed to get the maximal possible difference 25, even if this means choosing the 
smaller argument of choose (in particular, we pick 30 for x\ and 5 for X2). 

If we included lists in our language, we could adapt pickMax to a handler pickAII 
that select all possible results [5]. To do so, the return clause would return a sin- 
gleton list containing the returned value, while the decide clause would concatenate 
the lists x t and Xf that result from yielding both possible results to the handled 
continuation. 

2. 3. 2 Backtracking 

To implement backtracking, where we employ non-deterministic search for a given 
solution, we add an operation fail to signify that no solution exists. Then, for 
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example: 


rec fun chooselnt (m, n) H > 
if m > n then fail () else 
do b decide () in 

if b then (return m) else chooselnt (in + 1, n) 

is a function that non-deterministically chooses an integer in the interval [m, n], or 
fails if this interval is empty, while: 

Pythagorean = f fun (m, n) H ?■ 

do a <— chooselnt (m, n — 1) in 
do b <— chooselnt (a + 1, n) in 

if isSquare (a 1 + b 2 ) then (return (a, b, \J a? + b 2 )) else fail () 

is a function that searches for an integer Pythagorean triple (a, b , c) such that 
m < a < b < n. We perform backtracking by handling each decide by first trying to 
yield true, and if this fails, yield false: 


backtrack = handler {decide(_; k ) H ?• 

with 

handler {fa i I ( ; ) k false} 

handle 
k true} 

Then, with backtrack handle Pythagorean ( m,n ) finds (5, 12, 13) for (m, n) = (4, 15) 
but fails for (m, n) = (7,10). The exact triple found depends on the implementa- 
tion of the handler. If, instead, we first tried yielding false, the resulting triple for 
(m, n) = (4, 15) would be (9, 12, 15). To get a list of all possible triples, we can use 
the handler pickAII from Section 2.3.1, but extended with a clause that handles fail 
with an empty list. 


2-4 State 

We represent state with operations set for setting the state contents, and get for 
reading them. For simplicity, we assume a single memory location that holds an 
integer. So, set takes an integer, stores it, and returns a unit result, while get takes 
a unit parameter, reads the stored integer, and returns it. 

We can use handlers to temporarily alter the stored value or to log all updates. 
But we can also use them to implement stateful behaviour even if we do not assume 
a built-in one. Like in Section 2.1.3, we use a parameter-passing handler to pass 
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around the current state: 

state = f handler {get(_; k) fun s H > (ks) s 
set(s; k) fun _ ^(k())s 

return x fun _ i-> return a:} 

We handle get with a function that takes the current state s and passes it first 
as a result of get to the continuation, and then again as the unchanged state. 
Conversely, we handle set by first yielding the unit result, and then applying the 
handled continuation to the new state s as given in the parameter of get. 

The return clause of state ignores the final state, but if we want to inspect it, 
we can return it together with the final value by changing the return clause to: 

return x H > fun s i— > return (s, x ) 


2-4-1 Transactions 

In a similar way, we can implement transactional memory, where we commit the 
changed state only after the handled computation successfully terminated with a 
value, so in case an exception is raised, the memory contents remain unchanged: 

transaction = f handler {get(_; k ) H » fun s4 (ks) s 

set(s; k) fun _ -►(*())* 

return x fun s 1 — 5 - set s; return x} 


3 Operational semantics 

To make the intuition about the behaviour of computations concrete, we now give 
an operational semantics. The idea behind it is that operation calls do not perform 
actual effects (e.g. printing to an output device), but behave as signals that prop- 
agate outwards until they reach a handler with a matching clause. For simplicity, 
any operation call that escapes all handlers will be treated as a terminating com- 
putation, i.e. one that does not further reduce. We can assume that actual effectful 
behaviour is simulated by an outermost handler, or consider one of the approaches 
listed in Section 6.5. 

Small-step operational semantics is given using a relation c d , defined in Figure 3. 

Observe that there is no such relation for values, as these are inert. The rules for 
conditionals and function application are standard. For sequencing do x <- c\ in C2, 
we start by evaluating c\. If this returns some value v, we bind it to x and evalu- 
ate C 2 . But if ci calls an operation, we propagate the call outwards and defer further 
evaluation to the continuation of the call, as shown in Figure 4. 

For handling with h handle c, the behaviour is similar. We start by evaluating c, 
and if it returns a value, we continue by evaluating the return clause of h. If c calls 
an operation op, there are two options: if h has a matching clause for op, we start 
evaluating that, passing in the parameter and the handled continuation; if not, we 
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ci c 1 


do x ci in C 2 ^ do x <— c^ in C 2 


do x <— return v in c ^ c[v/x] 


do x <— op(i;; y. ci) in C 2 op(u; y. do x <— ci in C 2 ) if true then ci else C 2 ci 


if false then ci else C 2 ^ C 2 (fun x \ c)v c[v/x] 

In the following rules, we set h = handler {return x c r , op 1 (rr; k) »-»• ci, . . . , op n (rr; k) c n }: 


with h handle c with h handle c 


with h handle (return v) c r [v/x] 


with h handle op i (v,y. c) a[v/x, (fun y with h handle c)/k] (1 < z < n) 

with h handle op(u; y. c ) ^ op(u; y. with h handle c) (op 0 {opj^ , . . . , op n }) 


Fig. 3. Step relation. 


do x\ <— (do X2 <— op(rr; y. C2) in ci) in c ^ 
do xi <— op(a:; y. do X2 <— C2 in ci) in c 
op(x; y. do x\ <— (do X 2 <— C 2 in ci) in c) 


Fig. 4. The call of op in the innermost sequencing propagates outwards until it reaches the top. 

propagate the call outwards and defer further handling to the continuation, just like 
in sequencing. 

4 Type system 

To ensure that the evaluation goes smoothly, we introduce a type and effect system 
along the lines presented in [4,10]. Just as we split terms into values and compu- 
tations, we split types into value types and computation types , given in Figure 5. 


value type A , B 


computation type C, D 


bool 

A—>C 
C_=> D 

A!{°pi, . . . ,op„} 


boolean type 
function type 
handler type 


Fig. 5. Syntax of types. 


The value type A — » C is given to functions that take a value of type A and perform 
a computation of type C_, while the handler type C => D is given to handlers that 
transform computations of type C into ones of type D. Every computation type 
has the form A ! A, where A is the type of values the computation returns, and A 
is the set of operations it possibly calls, i.e. the set A is an over-approximation of 
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the operations that are actually called. Also note that A contains no information 
about the number of occurrences, passed parameters, or order of operations. 
Typing information about operations is given in a signature S of the form 

{op! : A l ->■ Bi, . . . , op„ : A n -s- B n } 

which assigns a parameter value type Ai and a result value type B t to each opera- 
tion op,,;. 

Example 4.1 Assuming that value types are extended with types int of integers, 
str of strings, unit, which is given to the unit value (), and the empty type void, the 
operations we have seen in Section 2 can be assigned the following types: 

print : str — » unit 
read : unit — » str 
raise : str — > void 
decide : unit — > bool 
fail : unit — > void 
get : unit — > int 
set : int — > unit 

Since there are no values of the void type, a call to raise or fail effectively aborts 
the continuation, because there are no handlers that could resume it by yielding a 
suitable value. 

In Figure 6 we define two typing judgements: T h v : A for values and T h c : C 
for computations. In both, the context T is a assignment of value types to variables. 


(i:A)er 

r h x : A r h true : bool T I- false : bool 


: A h c : C 

r h fun x H > c : A — > C 


T, x : A h c r : B ! A' 

[(o Pi : Ai ->• Bi) € S V , x : Ai, k : B t B \ A' \- a : B\ A'l A \ {o P! } 1<i<n C A' 

L J l<i<n 

r h handler {return x i— »• c r , op 1 (ai; k) i— >■ ci, . . . , op n (x; k) h* c n } : A ! A => B ! A ; 


r h v : A 

r h return v : A ! A 


(op : A op B op ) GS T \- v : A op T, y : B op b c : A ! A op G A 
r b op(i;; y. c) : A ! A 


r b ci : A \ A r,x : A\~ c 2 : B\A 
r b do x <— ci in C2 : B ! A 


r\-V!: A ->C T b v 2 : A 
r b vi V 2 : C 


rbv: bool r b Cl : C T b c 2 : C 
r b if v then c± else C2 : C 


r\-v :C^D rb c:C 

r b with v handle c : D 


Fig. 6. Typing judgements. 


Typing rules hold no surprises except for: 
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Return You might expect the conclusion to be T b return v : A ! 0 as that is 
the most precise type one can assign. However, we give all the rules in a form 
that allows coarser types because this loses no generality (e.g. in this particular 
rule, we can set A = 0), is sufficient for our purposes and leads to a simpler type 
system. See [23] for an algorithm that produces a more precise type. 

Operation call Here similarly, we can assume that although A contains op, it can 
be assigned to the continuation c even when c does not call op. 

Handling According to the above interpretation that C => D is given to handlers 
that take computations of type C to ones of type D, it is not surprising that 
handling behaves like an application of a function. 

Handler To give handler a type A ! A => B\ A', we need to check that it correctly 
handles returned values and operations both with and without a matching oper- 
ation clause. For return values, it is simple: given a value of type A, the return 
clause must be a computation of type B ! A'. 

Next, for each handled operation op^ : Ai — > the handling clause again needs 

to be a computation of type B ! A'. Here, the parameter is expected to have the 
type Ai as determined by S. Similarly, the captured continuation is a function 
that takes a result of type Bi and performs a computation of type B ! A'. Notice 
that even though the handled computation has type A ! A, the continuation has 
a different type because it is further handled. 

Finally, we want to handle computations that call operations without a match- 
ing operation clause in the handler. For this case, we allow A to contain oper- 
ations not in {opji^^n, but any such operation must also appear in A' as it 
may also be called in the handled computation (and thus also in continuations of 
handled operations). 

The given typing system then ensures that well-typed computations do not get 

stuck [4]. 

Theorem 4.2 (Safety) If b c : A ! A holds, then either: 

• c = return v for some b v : A, or 

• c = op(w; y. d) for some op € A, or 

• c d for some b d : A ! A. 


5 Reasoning 

Recall that two terms are observationally equivalent [8] if we may exchange any 
occurrence of the first with the second without affecting the observable properties 
of the surrounding program. Due to the separation in the syntax, we define obser- 
vational equivalence of both computations (c = d) and values (v = d). We can 
show [4] that = is a congruence and that it satisfies a collection of basic equivalences 
given in Figure 7. 

The main new tool we can use for reasoning about algebraic effects is the induction 
principle [20,4], which states that for a given predicate <f> on computations, 0(c) 
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do x return v in c = c[v/x] (1) 

do x <— op(u; y. ci) in C2 = op(u; y. do x <— c\ in 02) ( 2 ) 

do x <— c in return x = c ( 3 ) 

do X2 <— (do xi <— ci in C2) in C3 = do x\ <— ci in (do X2 <— C2 in C3) ( 4 ) 

if true then ci else C2 = ci ( 5 ) 

if false then ci else C2 = C2 ( 6 ) 

if v then c[true/x] else c[false/:r] = c[v/x\ ( 7 ) 

(fun x 1 — ^ c) v = c[v/x] (8) 

fun x v x = v ( 9 ) 

In the following rules, we have h = handler {return x \ — >■ c r , op 1 (x; k) ci, , op n (x ; k) h-> c n }: 

with h handle (return u) = c r [v/x] (10) 

with h handle (op i (u; y. c)) = Ci[v/x, (fun y with h handle c)/k] (1 < i < n) 

(11) 

with h handle (op(u; y. c)) = op(u; y. with h handle c) (op ^ {op i }i<i< n ) (12) 

with (handler {return x 1— ^ C2}) handle ci = do x <— ci in C2 ( 13 ) 


Fig. 7. Basic equivalences. 


holds for all computations c if: 

(i) ^(return v) holds for all values v, and 

(ii) (f){ op(u; y. c')) holds for all operations op and parameters v, if we assume that 
</)(c') holds for all possible results y. 

We can use the induction principle to derive equivalences (3), (4), and (13), but 
for a more interesting example, let us show that handlers collect and collect' from 
Section 2.1.3 exhibit equivalent behaviour, in particular: 


with collect handle c = do g -s— (with collect' handle c) in g 


To succeed with induction, we need to prove a stronger statement that for any string 
so, we have 


do (a?i, Si) •(— (with collect handle c) in return (xi, join So Si) = 
do g <— (with collect' handle c) in g sq 


We recover the desired goal by setting so = The induction on c goes as follows: 

(i) The base case is trivial: if c = return v, both sides are equal to return (w, so). 

(ii) For the induction step when c = op(u;t/.c'), we have two possibilities: either 
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op ^ print, which is again trivial, or op = print, where we show: 

do (xi, si) <— (with collect handle print(s 2 ; — c. ')) in return (xi, join so si) 

= ( 11 ) & ( 8 ) 

do (Xl,Sl) <r~ ( 

do (x, acc ) <— (with collect handle d) in return (x, join S 2 acc ) 

) in return (xi, join So si) 

= (4) 

do (x, acc) (with collect handle d) in 

do (xi, Si) (return (x, join S 2 acc)) in 

return (xi,join so si) 

= ( 1 ) 

do (x, acc) <— (with collect handle d) in return (x, join so (join S 2 acc)) 

= (associativity of join) 

do (x, acc) <— (with collect handle d) in return (x, join (join so S 2 ) acc) 

= (induction hypothesis) 
do f <— (with collect handle d) in / (join s 0 S 2 ) 

= ( 1 ) & ( 8 ) 

do g - 5 — return ( 

fun acc 1 — ^ do / •(— (with collect handle d) in / (join accs 2 ) 

) in g s 0 

= ( 11 ) & ( 8 ) 

do g <r- (with collect' handle pri nt(s 2 ; c')) in g so 

6 Further reading 

6.1 Call-by-push-value 

Call-by-push-value [12] is an evolved version of the fine-grain call-by-value approach. 
Though the latter was used in this tutorial as it is closer to the more familiar call- 
by-value, a significant part of the recent work on algebraic effects uses the former. 
To compare given operational semantics and effect system to ones done in a call-by- 
push- value setting, see [10], while for denotational semantics and reasoning, see [22]. 

6.2 Programming with handlers 

The list of examples in Section 2 is by no means exhaustive. For more involved ex- 
amples that include multi-threading, delimited continuations, selection functionals, 
text processing, resource management, efficient backtracking, or logic programming, 
see [5,10,6,25]. A number of implementations of handlers has also sprung up, either 
as independent languages [3,14], or as libraries in existing languages [10,6,25]. More 
recently, a multicore [2] branch of OCaml [1] has started adopting handlers as a 
way of implementing concurrency primitives. 
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6.3 Denotational semantics 

In the naive setting where operations return only first-order values and there is no 
recursion, we can interpret each value type A with a set [A], while a computation 
type [A ! A] is interpreted as the set of trees (like ones described in Section 1) with 
leaves in [A] and nodes corresponding to operations in A. Handlers are interpreted 
as functions between trees, and are defined by structural recursion on the tree of the 
handled computation, while handling is interpreted by application of such functions. 

More abstractly, we define a model of A to be a set M together with a map 
op M : [A] x Ml 5 ! — > M for each operation op : A — > B G A, while a homomor- 
phism between models M and N is defined to be a map h: M — ?• N such that 
( h o op M )(x, k) = op N (x, h o k). It turns out that [A ! AJ is exactly the free model 
of A over [A], i.e. a model characterized with the following universal property: 
given any model M of A and any map /: [A] — > M, there exists a unique homo- 
morphism h : [A ! A] — » M that agrees with / on leaves. We can use this universal 
property to interpret handlers: operation clauses define a model of operations, and 
the return clause provides a function / that can be extended to a homomorphism. 

For more detail, see [22]. In the general setting with recursion and higher-order 
results, we need to switch from sets to domains, but the general idea is the same [4]. 

6.J t Algebraic theories 

Traditionally, algebraic effects were described not only by a set of operations, but 
also by an equational theory that captures their properties. For example, nondeter- 
minism can be represented with a binary operation decide and equations stating its 
idempotency, commutativity, and associativity [18,9,17]. The benefit of equations 
is that they validate certain program optimizations [11] and better capture the ef- 
fectful behaviour of operations. With various extensions of such theories, one can 
also describe complicated effects such as control-flow jumps [7] even in the absence 
of handlers, or quantum computation [24]. 

However, a lot of computationally interesting handlers (for example backtrack 
from Section 2.3.2) do not respect these equations and thus cannot receive a ho- 
momorphic interpretation described above [22]. For this reason, current research 
on handlers assumes no such equations, but connections exists in both directions: 
on one hand, we can still apply previous results by assuming a trivial equational 
theory, and on the other hand, we can use reasoning techniques to recover equations 
from the behaviour of handlers [4] . 

6.5 Modelling actual effects 

One can model “real-world” effects with a comodel, which is a set W representing 
the possible world states together with a map op u : W x [AJ — ;• W x [HJ for each 
operation op : A 4 B £ S. Thus, when an operation call op(v; y. c) escapes all 
handlers, we pass the current state w G W and the parameter v to op n and get 
back the new state and a result, which we assign to y and continue evaluating c. 
For more details, see [5, Section 4.1], which is based on a more abstract treatment 
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in [19], where the duality between models and comodels is explained in more detail. 
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